[レポート] プロダクトバックログ Deep Dive #RSGT2022

Regional Scrum Gathering℠ Tokyo 2022

#スクラム

#アジャイル

#セッションレポート

aratafuji

2022.01.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、グローバル事業部の藤村です。

2022年01月05日(水)〜2022年01月07日(金)の3日間、現地(東京：御茶ノ水ソラシティカンファレンスセンター)及びリモートでのハイブリッドで開催されたスクラムイベント『Regional Scrum Gathering℠ Tokyo 2022』に現地参加してきました。

当エントリでは、2日目に開催されたセッション「プロダクトバックログ Deep Dive」のレポートを紹介します。

セッション概要

イベントサイトで公開されている発表内容の「概要」は以下の通りです。

プロダクトバックログ Deep Dive

プロダクトバックログのすべてを完全解説!!

スクラムにおいて、プロダクトバックログは肝となる要素の1つです。プロダクトバックログがなければスプリントは始められないですし、単に要件を切り刻んで並べたようなプロダクトバックログでは変化にも対応できません。

スクラムガイドを見ると、プロダクトバックログの作り方、書き方、維持や管理の仕方については、多くは触れられておらず、多くの人は実践で試行錯誤しながらより良いプロダクトバックログを目指して改善を続けられているのではないかと思います（それはそれで素晴らしい）。

一方でプロダクトバックログを誤解しているのもよく見かけます。すべてをユーザーストーリー形式で書く必要もないですし、全部を同じ具体性にする意味もありません。すべてのプロダクトバックログアイテムをプロダクトオーナーが作らなければいけないわけでもないですし、すべてのプロダクトバックログアイテムを実装しなければいけないわけでもありません。Webアプリケーションでログイン機能がプロダクトバックログの上位に必ず来るわけでもありません。

本セッションでは、プロダクトバックログをうまく使えるようになるための基本から応用まで、Scrum Alliance認定スクラムトレーナー(CST-R)、認定チームコーチ(CTC)の吉羽が体系的に解説します。

セッション発表資料

こちらのセッションは既に資料が公開されています。スライド資料は以下。

セッションメモ

プロダクトバックログは重要
- 2020は全体がコンパクトになったため登場回数が減った
良くない例
- 砂嵐、荒野、ぺんぺん草も生えない
- ごちゃごちゃな密林
良い例
- 整備された庭
- 日々ちょっとずつ手入れされてる
ポイント
- 創発的
  - 後から後から出てくる
- POが管理の責任を持つ
  - 作業自体は委任できる
- PBL
  - プロダクトゴール＋ PBI
プロダクトビジョンとプロダクトゴールの違い
- ビジョン
  - 抽象的
- ゴール
  - 計測可能
  - 特定の期間で完成させる
    - 同時に一つ
PBI
- 書き方は不定
- 最低限、順番、内容、見積もりがあれば良い
管理方法
- オススメはGoogle Spreadsheet
- スクラムチーム全員が末尾に追加できる
スプリントの進め方の大原則
- スプリントゴールやスプリントレビューから逆算する
- インクリメントを見せられないのは論外
- 「生煮えプロダクトバックログアイテムを食べると腹を壊す」
Sサイズを沢山投入するのも良くない
ミニウォーターフォールにならないように
完成しなかったら「再見積もり」してプロダクトバックログに戻す
PBIが100個を超えるとメンテナンスが大変
ユーザーストーリー
- 意図的に沢山書けない制約
PBIの原則
- やりすぎ注意
  - 必要に応じて付け足していく
避けたい
- ほしい理由が何も説明されてないPBI
- 画面単位PBI
  - 大きすぎる
  - 必須のものと、必須ではないもの
- デプロイを自動化したい
  - ソリューションを示している
リファインメントはイベントではなく活動
プロダクトバックログの手入れをしないので時間がなくなる
分割後、分割前のPBIは不要
具体的な分割指針
- ワークフローのステップ
- ビジネスルール
- ハッピーパスとそれ以外
- プラットフォーム
- 入力パラメータ
- CRUD
- 利用者の役割
- 最適化の度合い
- ブラウザなどのバージョン
ログイン機能は先に作るべきか？
- 内部的に固定ユーザーでもできる
初期のPBLの作り方
- まずはプロダクトゴールを考えよう
- 最初に誰か一人がPBLを全部作れるなら、スクラムである必要はないかも
- MVPを特定する
- どうせ初期のPBL全部作ることはない

まとめ

スクラムガイドを読むだけではなかなか理解することが難しいプロダクトバックログの作り方、手入れの仕方がとても具体的に整理されていました。まさに整備された庭のようなセッション内容！

私自身、スクラムに取り組み始めた当初はスクラムガイドやスクラムの書籍などを読みながら試行錯誤を進める中で、「このやり方で良いんだろうか」、「全然見当違いなことをやっちゃっているのではないか」などとても不安な気持ちになっていた覚えがあります。そんな時に今回のセッションを聞くことができていたら、「自分が試行錯誤の末にたどり着いたやり方で良かったんだ！」、「スクラムガイドの意味を誤解しちゃってた。早速改善だ！」など、とても学びが多かったと思います。

一方、既に何年もスクラムに取り組んできている私にとっても、うまく言語化できていなかったことが網羅的に整理されていて、プロダクトバックログに関する知識がとてもクリアになったと感じています。今後関係者に説明する際に、ぜひ参考にさせてもらいたいと思いました。

なお、私自身がスクラムを実践する中で、少し違ったアプローチをしちゃっているなと感じた点も少しだけありました。主な点としては、以下の2点があります。

初期のPBLの作り方
- プロダクトビジョンは先にある
- まずはユーザーストーリーマッピングを実施し、その活動を通してMVPを含む複数のフェーズ、プロダクトゴールを設定することが多い
スプリントで完成しなかったPBIの扱いについて
- "完成しなかったら「見積もり(相対ポイント)は変えずに」プロダクトバックログに戻す" ようにしている（そのように教えている）

前者については、"みんなでプロダクトバックログの候補を考える"具体的な手段としてユーザーストーリーマッピングは適していると考えているので、プロダクトビジョンだけでなく、まずはプロダクトゴールを考えるというステップを意識してみようと思いました。

後者については、以下のように考えていました。

スプリントで完成しなかったからといって、そのPBIの相対的な大きさが変わったわけではない
もし今後のスプリントでそのPBIを完成させた場合、平均的なベロシティがより実態に近くなる
- 8ポイントのPBIがスプリントnでは完成しなかった
  - 当スプリントのベロシティは0
- 該当PBIをスプリントn+1でも選択し、完成した
  - 再見積もりした結果が3なら、当スプリントのベロシティは3
  - 見積もりは変えなかったら、当スプリントのベロシティは8
- 平均ベロシティ
  - 再見積もりした場合は1.5
  - 見積もりを変えなかった場合は4